From VoIP to Real-Time Multimedia and IMS

By Ken Kuenzel

The result is that just as email revolutionized mail by delivering text information anywheThe days of Voice over IP (VoIP)
telephony as a lower-cost version of
what is available over the public switched telephone network (PSTN) are over. With the wide-scale adoption of the Session Initiation Protocol (News - Alert) (SIP), we are moving rapidly beyond Voice over IP (VoIP) to the delivery of real-time services over IP. These services can integrate voice, video and enhanced services within a single session. For example, from a desktop application, a user can escalate an instant messaging (IM) conversation to a voice call and then share a video file and collaborate on a PowerPoint presentation, all within the same session. re in the world within seconds, real-time services will transform communications by delivering voice, video, IM, presence and many other advanced services within milliseconds. Interactive, instantaneous communications have become a reality, and users can now collaborate in ways far more rich and expressive than ever before.

Service providers are looking to the IP Multimedia Subsystem (News - Alert) (IMS) to define the architecture and standards that support the delivery of these new applications. IMS is an industry-wide architectural effort intended to enable carriers and other service providers to offer a broad variety of IP-based services to fixed and mobile customers. While its origins were for 3G mobile networks, IMS has expanded to include the needs of next-generation wireline networks. Increasingly, competitive forces are driving service providers to go beyond VoIP to deliver real-time services now, while they simultaneously plan and execute the evolution of their infrastructures towards full IMS compliance. As a result, many service providers cannot jump directly to IMS; they must proceed in phases.

• VoIP Transport: The first step to IMS adoption has already been reached as carriers worldwide have replaced, or at least augmented, their traditional TDM networks with IP transport and softswitches. (See
Figure 1.)

• Connecting Users to Services: The next step—the “pre-IMS” phase— has already begun for many service providers. In this phase, service portfolios expand beyond voice telephony to include video, IM and other presence-enabled applications—often in use all at once—over “toll-quality” connections.

• IMS Compliance: The last step is a transition to an IMS-compliant infrastructure to provide more control structure and application layering to further reduce complexity and costs and provide the delivery of new advanced capabilities.

Phase 1: VoIP Transport
The telecom industry has already reached the first stop on the road to IMS adoption. Carriers worldwide have replaced, or at least augmented, their traditional TDM transport networks and Class 4 switches with more economical IP transport and softswitches. A large percentage of long distance voice transport now relies on IP. For end users, however, little has changed; their telephony experience is the same as with TDM transport.

Most users are not aware that phone calls must often traverse multiple carrier networks. At first,VoIP calls required traversing as well—the sessions were converted from IP to TDM and back again to create the necessary peering connections. Direct IP-to-IP interconnect would have been more efficient, but the addressing constraints of IPv4 and various security and performance concerns got in the way.

Session Border Controllers (SBCs) were invented to overcome these limitations and allow direct interconnect between VoIP backbones.With features like NAT traversal, topology hiding, QoS enforcement and denial of service (DoS) protection, interconnect SBCs make IP-to-IP carrier interconnect safe and practical.

Phase 2: Connecting Users to Multimedia Services
In the next phase of the journey from VoIP to IMS—a phase that many service providers have already begun—IP-based realtime services extend all the way to end users, creating a variety of new user experiences. At the same time, service portfolios expand beyond voice telephony to include video, messaging and other presence-enabled applications—often in use all at once—over “toll-quality” connections. (See Figure 2.)

In a multimedia service deployment intended for IMS migration, the deployment model would closely follow the IMS model:

Application Layer — VoIP, video, IM, presence, servers

Control Layer — The SBC as the Control Function

Transport Layer — Switches, routers, gateways

SIP becomes the dominant signaling protocol in this phase, and certain IMS elements like the Home Subscriber Server (HSS) may also be deployed. But Phase 2 is still “pre-IMS,” delivering the sort of real-time multimedia experience that IMS is intended to support, but without the benefit of the full IMS control structure or its strict application layering.

Phase 3: Standard Application and Session Control
Phase 3 completes the integration of SIP and IMS into the carrier infrastructure. Universal use of SIP puts an end to vendor-specific protocols and promotes application and endpoint interoperability. It also breaks down barriers between disparate networks, facilitating fixed-mobile convergence and other advanced capabilities. The layered IMS framework accelerates service creation and delivery by eliminating the smokestack architectures that tie applications to specific network equipment. And by enabling consistent behavior across diverse access networks, IMS increases the reach and productive lifespan of new multimedia services.

Navigating from “Pre-IMS” to IMS
There are many fixed-line and mobile carriers that are piloting these services today and the best practices that have arisen from these trials are presented below. Since none of these organizations have migrated completely to IMS, the reader should view these recommendations as the “best practices” or “lessons learned” from companies that are deploying and managing large-scale SIP-based services with the intent of moving to IMS compliance in the near future.

The Access Edge is Not the Peering Edge. IMS defines two types of Session Border Controllers. The access-edge SBC connects users to VoIP and other real-time services, and the peering-edge SBC interconnects provider IP networks. In realworld deployments, this distinction is necessary because the requirements at the access edge are significantly different from the requirements found at a network-to-network peering boundary. For instance, the access edge has to process registration traffic, manage registration floods, secure user connections, protect the service from intrusions and attacks, enforce userdefined policies, terminate increasing numbers of resource intensive stateful connections (TCP, TLS) and, in certain instances, process media sessions (encrypt, decrypt, record, etc.) with negligible latency, jitter and loss. Experience has shown that an SBC not designed to meet theses challenges will fail at the access edge.

It’s About Multimedia Services, Not Just VOIP. VoIP is the baseline, but the mission is to deliver interactive, multimedia services that generate higher revenues and more productive business models, as well as make it easier for the provider to attract and retain customers. Completing this mission requires that the control layer (the SBC) be application-aware and able to provide a single point of policy-based security, control and management across any and all real-time services. An SBC that can provide content security for VoIP (encryption) but does not do the same for IM (virus scanning, content filtering, URL filtering, etc.) is essentially useless at the access edge of a multimedia services deployment.

Automated Provisioning and Management is Critical. Another unique challenge of the access edge is controlling, managing and provisioning service to tens-of-thousands or millions of users on many different types of active endpoints and across multiple networks. This problem is best addressed through a Web Services interface between the SBC and the Operational and Support systems.

Tier 1 and tier 2 service providers shouldn’t even think about deploying multimedia services to their subscribers unless they can assert dynamic control over the provisioning and management of real-time services. They also must be able to enforce dynamic control policies that determine which service options and levels a particular user is entitled to at a particular moment in time.

SIP Makes Migration to IMS Possible. The industry has decided that SIP is the signaling standard for all IP-based realtime communication and collaboration.Most softswitches, IP PBXs, application servers and enterprise collaboration platforms already support SIP, and the few that do not soon will. It is critical to make SIP the standard on the access side now and ensure that your SBC provides a robust SIP interoperability capability so it can overcome the inevitable interoperability issues that will threaten the next-generation access edge. An SBC that does not provide SIP interoperability is essentially useless at the access edge as the industry migrates to next-generation IP communication. An SBC that does
not provide
SIP interoperability is
essentially useless at the
access edge.

Deliver “Business-Grade” Services. Business users and the mass consumer market expect the same levels of security, reliability and quality of service (QoS) as they enjoyed with traditional phone service. Therefore, your service must meet the security, performance, quality and reliability thresholds for these customers.

Be certain your SBC provides the comprehensive applicationlevel security to protect your users and to defend the network from attacks and intrusions designed to degrade or disable service delivery. Also you’ll need to make sure that your SBC can scale performance and capacity predictably, without increasing management complexity. You’ll need to guarantee service continuity through equipment failures—remember that the goal here is to attract and retain new customers.

Think Web (Services). In a fully IMS compliant architecture, it is the IMS Service Control Interface (ISC) that defines how the application server communicates with the Call Session Control Function (CSCF) in the IMS control plane. All of the major application server providers have made their solutions IMS-ready by implementing the required ICS interfaces.

However, any discussion of interaction between the control and application layer in the “pre-IMS” phase should cover the collection of standards and technologies broadly defined as Web Services. Although Web Services are not directly related to IMS, they have been shown to be an extremely valuable approach that service providers planning on providing “pre-IMS” services should consider.

This consideration is necessary because the Web Services model isolates application logic from the mechanics of external protocol interfaces and network elements to create an interoperable network of reusable services. It also creates a services layer that facilitates the rapid creation, deployment and customization of real-time and data services. Web Services provide a critical abstraction layer between the control layer (SBC) and services layer (the in-place business systems) that will make full migration to IMS easier as the underlying architecture and components evolve.

In general, the web and Web Services (componentization with well-defined interfaces) provide excellent models for making architectural decisions that account for future developments.When in doubt, you should look to the models in use today for the deployment of mission-critical applications over IP.We have found that the specific implementations may differ, but the models in use today for HTTP applications transfer to the real-time environment.

Summary
The need for new revenue-generating applications and services is one of the main drivers for IP Multimedia Subsystem (IMS). However, service providers cannot wait for IMS to arrive before they begin offering new multimedia services, and as a result, many providers will proceed to IMS in phases. Although not without challenges, forward-thinking providers are managing the migration from “pre-IMS” to full IMS by following many or all of the guidelines presented here.

Ken Kuenzel is the founder, VP of engineering and CTO of Covergence. For more information, visit the company online at www.covergence.com.